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Abstract 

In this paper, we address the reentrancy vulnerability in 
smart contracts using two program logics. We first propose 
a coarse-grained logic that extends the standard Hoare logic 
by a proof rule for reentry trigger commands. We prove 
this logic sound and complete. We propose another fine¬ 
grained logic that considers reentry triggers as entry and 
exit points of functions. For verifying coarse-grained specifi¬ 
cations, these two logics have the same expressiveness, and 
we can derive coarse-grained judgments from fine-grained 
ones. In comparison, the fine-grained logic is more useful for 
fine-grained specifications. We use a toy language to demon¬ 
strate our results and we formalize all definitions and proofs 
in Coq. 

1 Introduction 

Smart contracts [25] are decentralized protocols automated 
by programs and deployed on blockchains, allowing trading 
without being supervised or intervened by any third party. 
Ethereum [9] is a successful implementation of this idea, 
where users use the Solidity [1] language to write smart 
contracts. However, catastrophic attacks in history unveil 
various vulnerabilities of Solidity contracts, including the 
reentrancy loophole we study, which is challenging to iden¬ 
tify during the development of contracts and has caused 
the infamous DAO attack [24]. This paper targets smart 
contracts’ functional correctness verification which takes 
potential reentry behavior into consideration. 

Reentries and reentrancy bugs. Figure 1 shows a simpli¬ 
fied version of the DAO attack. In this example, the simple 
bank contract maintains a state variable userBalance to 
store users’ deposits. User contracts can reclaim their de¬ 
posits by calling the withdrawBalance method, which is¬ 
sues the transfer at the 7th line and clears the balance at 
the 8th line. Solidity specifies that every transaction will 
trigger a fallback function in the receiver contract— this fall¬ 
back function is where the receiver could respond to the 
transaction. However, a potential attacker could leverage 
this mechanism to re-enter the withdrawBalance method 
before the execution of the 8th line. Thus, the control flow 
would form an infinite recursion between these two func¬ 
tions. The bank will constantly send Ether^ to the attacker 
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1 contract Bank{ 

2 mapping (address => uint) private 

userBalances ; 

3 function withdrawBalance () publicf 

4 uint amountToWithdraw = userBalances[ 

msg.sender]; 

5 if (amountToWithdraw > 0 ){ 

6 / reentry point 

7 msg.sender.call.value ( 

amountToWithdraw)(""); 

8 userBalances[msg.sender] = 0 ; 

9 } 

10 } 

11 } 

12 contract Attackerf 

13 Bank public bank; 

14 function!) payablef 

15 // reentrancy attack 

16 bank.withdrawBalance() ; 

17 } 

18 } 


Figure 1. The Simplified DAO Example [12] 


1 contract Bank{ 

2 mapping (address => uint) private 

userBalances; 

3 function withdraw!) public {...} 

4 function deposit!) public payable 

{. . .} 

5 function query!) public returns (uint) 

{. . .} 

6 } 

7 contract User{ 

8 Bank public bank; 

9 uint balance ; 

10 function!) payablef 

11 balance += msg.value; 

12 // re-enter query!) & deposit!) 

13 uint diff = balance - bank.query !) ; 

14 if!diff > 0 ){ 

15 balance -= diff; 

16 bank.deposit!).value(diff)!) ; 

17 } 

18 } 

19 } 


Figure 2. Potential Usage of the Reentrancy 

until gas^ runs out, and the attacker may eventually harvest 
more Ether than what it initially owns. 

^Gas measures the amount of computation required for one transaction, 
j Using up the gas undoes modifications to the state in the current call frame. 






The word "reentrancy" refers to entering a function, or 
more generally, a contract again during its execution without 
an explicit invocation. It is often caused by calling functions 
of external contracts that have another call to functions in 
the host contract. Standard practices fix reentrancy bugs 
by forcing variable updates before possible reentry calls or 
by introducing a mutex lock to forbid reentry calls [11]. 
However, we believe a contract preserving the reentrancy 
feature allows more automation for users who want to make 
valid adjustments upon transactions. An example in Figure 2 
allows reentrancy not only to the read-only method query, 
but also the non-static method deposit, where the user 
could secure its asset by always keeping half of its balance 
in the bank upon transactions. 

Functional correctness and interactive verification. Our 

strategy in this paper is to develop program logics for verify¬ 
ing functional correctness, while potential reentry behaviors 
are taken into consideration. In other words, we are not going 
to define and find what is wrong, but will define correctness 
and prove contracts correct (if they are indeed correct). This 
strategy has been proved successful by previous works like 
VST [4, 10] and Iris [20]. They formalize program semantics 
and program logics (usually a Hoare-like logic) in an interac¬ 
tive theorem prover (e.g. Coq) and prove them sound. Their 
users can use these logics to verify programs in the theorem 
prover. 

We follow their work flow: a program semantics that de¬ 
scribes potential reentry behaviors is first formalized; our 
program logics are then proved sound in Coq w.r.t. this se¬ 
mantics. Our program logics are extensions of Hoare logic 
and smart contracts’ functional correctness can be described 
by Hoare triples. 

Designing program logics for reentrancies. Reasoning 
about reentrancies is difficult because the fallback function 
is invisible from the verifier. Although some existing pro¬ 
gram logics and verification tools [4] can verify functional 
correctness when function calls and/or function pointers 
appear in programs, they only reason about known func¬ 
tions. In other words, their users need to write very specific 
assumption about callee functions / function pointers in pre¬ 
conditions and those assumptions describes the expected 
functionality of those functions. For Solidity contracts, the 
receiver’s fallback function is unknown from the sender. It 
can be even malicious. Due to this reason, many previous 
authors consider reentrancy-bug-free difficult to verify if 
using Hoare-like program logics [2]. 

Another difficulty is expressiveness. If excluding reen¬ 
trancy behavior, the execution result of a smart contract 
would be only determined by the initial state and the con¬ 
tract program itself. Thus, pre/postconditions would be ex¬ 
pressive enough to describe a program’s functionality—how 
the initial state determines the ending states. However, due 
to potential reentrancy, the ending state is also determined 


by those receivers’ fallback functions, i.e. determined by the 
number of reentrancies, the order of reentrancies and the 
arguments of reentry calls. Thus pre/postconditions are not 
expressive enough to describe all Solidity contracts’ func¬ 
tionality. 

For simplicity, we use a toy language to demonstrate our 
results. In this paper, 

• We define the syntax and semantics of the toy language 
with reentry trigger commands in §2. 

• We propose a proof rule for reentry trigger commands 
and develop a coarse-grained logic that can reason 
about reentrancy in §3. This logic is especially useful 
when reentry calls will not “interfere” original execu¬ 
tion. We use this logic to prove specifications for a toy 
example. 

• We propose another fine-grained logic to verify con¬ 
tracts with reentrancy in §4. We use an example to 
show its ability to reason about fine-grained specifica¬ 
tions where the coarse-grained logic would fail. 

• We describe the relationship between two logics and 
formalize it as a derivation theorem from fine-grained 
judgments to coarse-grained judgments in §5. We use 
previous toy example to demonstrate such relation. 

• We prove the coarse-grained logic complete in §6. 

We formalize two logics and all conclusions in Coq [7] (https: 
//github.com/BruceZoom/Reentry). 

Remark. The concept of the "reentrancy" is as well a term 
in the concurrent program context, where "a program is reen¬ 
trant if distinct executions of the program on distinct inputs 
cannot affect each other, whether run sequentially or concur¬ 
rently” [27]. This is a more general concept of the reentrancy 
in smart contracts, where we only consider reentrant pro¬ 
grams running sequentially. 

2 Preliminary 

In this section, we set up a simple imperative language and 
its denotational semantics, which contains functions and 
reentry calls. They will be the focus of program logics we 
propose in §3 and §4. 

2.1 Programming Language 

Figure 3 shows the syntax of the programming language with 
reentry calls. We use global v and local v to denote global 
and local variables, where v stands for variable names. The 
arithmetic expressions and boolean expressions are defined 
as normal. 

In Solidity, the host contract does not explicitly issue reen¬ 
try calls, and reentrancy is more like the side effect of a 
transfer statement. From this point of view, we may treat 
such transfer as two separate steps: the execution of intended 
operations and the execution of reentry calls. Knowing one 
command that might cause reentrancy, we can mark it as a 
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n • • • , —1, 0,1, • • • (number) 

V x,y,. .. (variable name) 

V local V I global v (variable) 

E n\V \ E + E (expression) 

I 

B true I false | \B (boolean expression) 

I £ == £ I £ < £ I B&&B 

C := skip I y = £ I reentry (command) 

I if B then C else C fi 
I while B do C od|C;;C 
I Call/£ 

Figure 3. Syntax of the language with reentry calls 


reentry point and apply the effect of reentry calls to the pro¬ 
gram state at that point. In our toy language, the primitive 
command reentry defines those reentry points in programs. 

Remark. Although we list the command Call/£ in Fig¬ 
ure 3 for regular function invocation of / with arguments 
£, but for clarity, we will not consider it in the discussion 
throughout the paper, i.e., we only consider a language ex¬ 
cluding the Call command. However, both languages share 
many similarities and we formalize all conclusions for both 
versions in Coq. 


Corresponding to the distinction of local and global vari¬ 
ables, we model the program state S as a tuple of a local 
state Si and a global state Sg. The local and global states are 
mappings from variable names to variable values. We define 
evaluations of variables and updates of program states as 


Pocal u|s 
[[global u|s 
S [(local v) i—> n] 
S[(global v) H-» n] 


Ms, 

1^1 

(S,[u n],Sg) 
(Si,Sg[v n]) 


On the right hand side, [[w|s is the regular evaluation of 
V on the global/local state S_, and S_[u i—> n] is the regular 
update on S_ that changes the value for v to n. 

Reentrancy happens in a program organized with func¬ 
tions, so we formalize the function model as follows. 


Unlike Solidity, our toy language is not object-oriented. 
We consider the entire known function context to be one 
contract and use global program states to describe contract 
states, while local states are only for temporary variables 
during execution. Such practice is well-defined since we 
only need to see the host contract and should not make any 
assumption about external contracts that are unknown to 
developers. 

2.2 The Denotational Semantics 

We present the coarse-grained denotational semantics for 
the toy language in Figure 4, where (If, F, C, Si) [[ (S 2 ) means 
that given function context IT and white-list F, the execution 
of C can change the program state Si into S 2 , and the arbitrary 
evaluation relation 11, F 1= S^ Sg means the reentrancy 
can change the global state Sg into Sg. 

The evaluation relation and the arbitrary evaluation rela¬ 
tion are mutually defined. The arbitrary evaluation relation 
is a binary relation of global states. We define it as the reflex¬ 
ive, transitive closure on the global effect of calling functions 
in white-list F. Reentry calls do not alter local program states 
of the caller and the arguments of the reentry call is directly 
instantiated into the local state of the callee. The global state 
after the reentry point can be any descendant of the original 
global state in the arbitrary evaluation relation, in accor¬ 
dance with the indefiniteness of the reentry call. In other 
words, the semantics of reentry is defined to be demon- 
icly non-deterministic, since the receiver can be malicious. 
Semantics for other commands are defined as normal. 

3 A Coarse-Grained Logic for Reentry Call 

In this section, we extend the Hoare logic [17[ by adding the 
Reentry rule to reason about reentry calls. The judgement 
of the logic has the form of 

n,r,Ah{p}c{g} 

which declares that the precondition and postcondition of 
command C are respectively P and Q, under the given 
function context 11, white-list T, function assumptions A. 
Function assumptions is a set of function triples with func¬ 
tion name and the pre/post-conditions of the function: 


F : list of function names 

n : function name —> (list of variable names X command) 

We use a set of identifiers £ to denote function names. F 
is a white-list of function names for public functions that 
may be invoked during reentrancy^. We use FI to represent 
function context, a mapping from function names to function 
arguments (lists of identifiers) and function bodies (pieces 
of commands), which are denoted as argn(/) and bdyn(/). 


We define judgment’s validity as 

n,ri= {P}c{Q} UwSuS2.s^ ^p^ 

(n,r,c,Si)^(S2)^ 

S2^Q 

where S £ means the program state S satisfies assertion P. 

We distinguish local/global assertions with normal asser¬ 
tions to reason about reentry calls that only modify the global 
state. We define the following two predicates that restrict the 


^ In Solidity, external contracts can only issue reentry call to public functions 
visible to them in the host contract, not private functions that are invisible. 
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Skip (U, T, skip, S) || (S) Assign (D, T, x = £, S) || (S[x p|s]) 


n, r 1= -^ar 5 ' 

Reentry - 

(n, r, reentry, (S/, S^)) {{Si, S'g)) 


(n, r. Cl, Si) U (S2) (n, r, C2, S2) ^ (S3) 

Seq - 

(n,r,Ci;;C2,Si)^(S3) 

false (n,r,C2,Si)^(S2) 

If False - 

(n,r, if B then Ci else C2 fi,Si)i)(S2) 


ms, = true (n,r,Ci,Si)U(S2) 

Jp _ 

(n, r, if B then Ci else C 2 fi,Si)||(S 2 ) 
Pis ^ false 

While False - 

(n,r, while B do C od,S)||(S) 


Plsj = true (n,r,C,Si) II (S2) (n,r, while B do C od,S 2 ) || (S 3 ) 

While True - 

(n,r, while B do C od,Si)||(S 3 ) 


Empty Reentry Call II, F 1= S^ -^ar Sg 


Append Reentry Call 


feT U,T ^ SgS'g 

(n,r,bdyn(/),(s;,s;))U((s",s;)) 
n, r 1= Sj^ '^ar s'g 


Figure 4. Denotational Semantics: we underline new relations we add 


scope of an assertion to either local or global, where global 
(local) assertions do not constrain local (global) states. 

localP(P) WSl,Sg,,Sg2.{Sl,Sgr) ^ P ^ (S,,S^2) F P 

globalP(P) VS,i,S, 2 ,S 3 .(S,i,S^) ^ P ^ (S, 2 ,S^) ^ P 

3.1 Proof Rules 

Figure 5 shows proof rules in this logic, where we underline 
the Reentry rule that reasons about the reentrancy. 

We use an global invariant I to connect several reentry 
calls in the Reentry rule. To do so, every function in the 
white-list should have the invariant as both its precondition 
and postcondition in function assumptions A. The existence 
of the local assertion P ensures that the local state is un¬ 
touched by reentry calls. 

3.2 Soundness 

We prove the soundness of the logic stated in theorem 3.1. 

Theorem 3.1 (Soundess). Suppose that any specification in 
function assumptions is provable 

V{P'}/{e'} e A.n,r,A H {P'}bdyn(/){g'} 

And some triple {P}C{Q} is provable 

n,r,AH{p}c{g} 

Then the triple is also valid 

U,T^{P}C{Q}. 

We follow the standard proof technique [5] by introduc¬ 
ing the "validity from assumptions", which we denote as 
n, r, A 11 = {P}C{0} and define as 

V{P'}/'{e'} e A.n,r ^ {P'}bdyn(/'){e'} ^ 

n,rMnc{e} 


Skip D, F, A I- {P}skip{P} 

Assign Backward FI, F, A h {P[x 1 — > £]}x = £{P} 

n, F, A H {PjCiiei n, F, A H {e}C 2 {P} 

Seq - 

n,F,AH {P}Ci;;C 2 {P} 


n, F, A H {P A pllCiiQ} n,r, A h {P A ^p]}C2{Q} 
n,F,Ai-{P}if B then Cj else C 2 fi{0} 

n,F,AH{ 7 Ap|}C{/} 

While - 

n,r,A I- {7}while B do C od{7A-.|lB]} 


P h P' 

Consequence - 


n,F,A h {P'}C{Q'} 

n,r,Ah{p}c{0} 




Vx.local P(P(x)) Vx.globalP(7(x)) 

V/ e r,x.{7(x)}/{7(x)} e A 

Reentry - 

IF, F, A h {P}reentry{P} 

where R = 3x, P(x) A 7(x) 


Figure 5. Proof Rules in the Coarse-Grained Logic 


And our key steps are to prove the following lemmas. 

Lemma 3.2. FI,F, A h {P}C{Q} implies Il,T, A 11= {P}C{2}. 

Proof. We can prove the theorem by induction on the struc¬ 
ture of the proof tree, and proofs of most cases are as normal, 
leaving the base case for Reentry rule. We prove the case 
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by induction on the arbitrary evaluation relation in the se¬ 
mantics of reentry command, and the rest of the proof is 
trivial. □ 

Lemma 3.3. Suppose that any specification in function as¬ 
sumptions is provable 

W{P}f{Q} e A.n,r,A H {P}bdyn(/){g} 

Then we have these specifications are all valid 

V{P}/{Q} e A.n,r ^ {P}bdyn(/){g}. 

Proof. The proof for the lemma is standard [5]. □ 

The proof of theorem 3.1 is obvious given these lemmas. 
Later, we will show that this coarse-grained logic is not 
only sound, but also complete in §6. 

3.3 Examples 

3.3.1 Multi-Function Reentrancy 

Figure 6 uses a toy example to demonstrate typical applica¬ 
tions of this coarse-grained logic. 

fix) ■■ gO ■■ 

if(; == 0&&X >0) i + H-; 

i - X -, 12 - reentry; 

li : reentry; i -; 

Figure 6. Simple Reentrancy Example 

The contract in this toy example contains only two public 
functions f and g both containing one reentry command. 
The contract has one global variable i, which is initially set 
to 0, and users can set the value of i to any positive number 
once using function /. We want to prove the specification 

{pl = 0 A [xl = /c> 0}/(x){p'| ^kAk>0} (1) 

where p'| represents the value of variable i. This specifica¬ 
tion states that the value of i is correctly set to the value of x 
(a temporary local variable), if i has not been set before and 
X is positive. To prove it, we first construct A as 

A — |{P1 — n A n > 0}/{p'| = wAn>0}|weN*} 

, ( 2 ) 

U {{Pl — n A n > 0}^{p| = nAw>0}|neN*} 

where we need to show that any triple in it is provable. 

For function /, the following is obvious. 

Vx.{p'| — n An > 0}/(x){p'| — n A n > 0} (3) 

For function g, we need to prove the following. 

{p'l — n A n > 0}^(){p| = n A w > 0} (4) 

To prove this, we need to show that the triple (5) holds at 
the reentry point I 2 

{p| - n + 1 An > 0}/2 : reentry{p'| - n + lAn>0} (5) 


which we can use an existential quantifier to transform into 

{3m.{m — n + lAn>0)A (p| — m A m > 0)} 

I 2 ■ reentry (6) 

{3m.{m — n + lAn>0)A (p| — m A m > 0)} 

This can be easily proved by Reentry rule and triples in 
function assumptions (2). And we have that the assumptions 
A is provable and can be utilized. 

With the A, we can prove the specification (1) by proving 

{P1 = |[x| A |[x| = A > 0} 

li : reentry (7) 

{P1 = W A |[x| = A > 0} 

for the reentry trigger in function /. We again split the asser¬ 
tion into a local part and a global part using the existential 
quantifier 

{3n.(|[x| — n A k — n) A (p'| — n An > 0)} 

li : reentry (8) 

{3n.(|[x| — n A k — n) A (p'| — n An > 0)} 

which is apparent by Reentry rule and assumptions (2). 
Therefore, we prove the specification (1) of /. 

This example shows how to use Reentry rule to forward 
proofs at reentry points, and we also show the proof of a 
recursive reentrancy that modifies the global state in the 
middle way. The example also shows that the existential 
quantifier allows the split of assertions into global parts and 
local parts by introducing a logic variable, which is crucial 
to the proof of reentrancy in this coarse-grained logic. 

3.3.2 DAO Example 

Figure 7 shows the simplified implementation of the DAO 
example in our toy language, where (9) is vulnerable to 
reentrancy attack while (10) is safe with reentry calls. We 
use a global variable balance to represent the recorded de¬ 
posit of the target user, and a global variable user to rep¬ 
resent the ether held by the user. The composite command 
user-l- = balance; / : reentry; simulates the transfer in 
Solidity, which transfer money to the user and then allow 
the user to perform reentry calls. 

withdraw))! 

if(balance > 0){ 

user -I- = balance; / : reentry; (9) 

balance = 0; 

}} 

withdraw))! 

if(balance > 0)! 

balance = 0; (10) 

user-H = balance; / : reentry; 

}} 

Figure 7. DAO in the Toy Language 



We would like to prove the specification eq. (11). 

{^balance^ — n A |[Mser| = m} 

Vm, withdraw() (11) 

{l^balance^ = 0 A |[user| — m + n} 

For (10), we need to prove {7}reentry{7} at the reentry 
point, where 7 = ^balance^ — 0 A |[Mser| = m + n. It is a 
valid invariant for the contract since {7}withdraw(){7} is 
obviously provable, and by the Reentry rule we can easily 
prove the specification. 

But for (9), we would require 

{^balance^ - n A |[Mser| - m + n} 

I : reentry 

{^balance^ - n A |[Mser| - m + n} 

which is not provable since in the reentry call we could add 
more to user by calling withdraw and no invariant could be 
found to prove the specification. 

4 A Fine-Grained Logic for Reentry Call 

One problem of our coarse-grained logic is the restricted 
expressiveness of function specifications: we cannot express 
a relation between ending states and (hyper-)parameters of 
reentry calls. For example, the best specification we can only 
prove for (9) is 

{^balance^ — n A |[Mser| = m} 

Vm, neN'*'. withdraw)) 

{3k. |[fca/ance| = 0 A |[Mser| — m + kn} 

However, we would like to show that the increment of user 
is related to the number of reentry calls to withdraw in the 
specification. We can accomplish this with the fine-grained 
logic we propose here. 

In this section, we pursue a different strategy: treating 
reentry as a special control flow and adding extra assertions 
for program states entering and leaving reentry. This idea 
is not totally new. Multi-postcondition are widely used for 
reasoning about break commands and continue commands 
[4]. Tan’s previous work [26] also uses multi-precondition 
and multi-postcondition for reasoning about non-structural 
jumps in assembly programs. We treat a function as a multiple- 
entry-multiple-exit code segment, where an entry or exit is 
marked by a label, which we define as 

L := entry | exit | I, li, h,--- 

where entry and exit describe the beginning and the end 
of a command, and Z, Zj, / 2 , • • ■ are unique line numbers of 
reentry commands in a function. We define a pair of func¬ 
tion name and label to be the index 

index := (/, Z) 

which uniquely^' determines a reentry point throughout the 
entire contract with multiple functions. 

^Two functions with the same function body might share the same label. 


The key idea is to use fine-grained judgments of the form 

U^{P}{Ri}C{R2}{Q} (12) 

where P, Q are regular assertions that specify the regular 
precondition and postcondition of the program C. Ri,R 2 
are mappings from indices of reentry points to assertions, 
which we name as reentry assertions. Ri specifies asser¬ 
tions that program states should satisfy when entering C 
through each reentry point, and R 2 specifies assertions for 
program states to satisfy when leaving C through each reen¬ 
try point. We will use f : {7’}{77i}{7Z2}{Q} as a shorthand 
for {7’}{.Ri}bdyn/{.R2}{C} in the rest of the paper. 

In short, P, Q corresponds to assertions at entry and exit, 
while Pi,P 2 corresponds to the preconditions and postcon¬ 
ditions at each reentry line number. A quintuple (the fine¬ 
grained judgment) says entering through any label (except 
exit) with corresponding precondition satisfied, if it leaves 
through any label (except entry), the program state will 
satisfy corresponding postcondition. Comparing with our 
coarse-grained judgements, these fine-grained judgements 
allow us to connect ending states with reeentry call argu¬ 
ments. 

Most proof rules are standard except the following one 
for the reentry command. 

Reentry {P}{Z : Q}1 : reentry{Z : P}{Q} 

The logic is known to be sound [26]. Thus we only focus on 
the validities of these judgments in this paper. 

4.1 The Fine-Grained Semantics 

We propose a fine-grained auxiliary semantics in Figure 8 to 
support the fine-grained logic. We use (11, C, Li, Si) J, (L 2 , S 2 ) 
to denote the fine-grained semantics of the execution trace 
in program C from entry Li to exit L 2 , where the program 
state changes from Si to S 2 . 

For the skip command and the assignment command, 
the program state pairs are the same as those in the coarse¬ 
grained semantics (see §2.2). The label pairs for them are 
entry and exit, meaning the execution trace starts from the 
very beginning and terminates at the very end of the com¬ 
mand, without triggering any reentry call. 

We treat the reentry command as an exit-entry point, 
where the execution trace can either leave the current func¬ 
tion to perform arbitrary reentry calls outside the contract 
or return from completed reentry calls to resume execution. 
Therefore, we split its semantics into two parts: Reentry 
Call states that after entering the reentry command, the 
reentrancy-free execution trace terminates at the location 
pointed by the concrete label Z with the program state S; 
Reentry Return states that if the interrupted execution 
trace returns to the function at Z, the control flow will exit 
the reentry point normally to resume subsequent execution. 
Here, the reentry trigger itself does not affect the program 
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Skip (D, skip, entry, S) J, (exit, S) 
Reentry Call (11, reentry, entry, S) J, (I, S) 


Assign (H, x = £, entry, S) J, (exit,S[x i—> |[-E|s]) 
Reentry Return (H, reentry, Z,S) J, (exit,S) 


(n, Ci,Li,Si) J, (exit,S2) 

(n,C2, entry, S2) i (12,83) 

Seq - 

(n,Ci;C2,Li,Si)i(L2,S3) 


(n,Ci,L,Si)i(z,S2) 

SeqI - 

(n,Ci;C2,L,Si)i(/,S2) 


(U, C 2 ,1, S,) 1(1,52) 

Seq2 - 

(n,Ci;C2,Z,Si)i(L,S2) 


iBlsj = true (11, Ci, entry, Si) J, (L, S 2 ) 

jp "Xrue _ 

(n, if B then Ci else C 2 fi, entry. Si) J, (L, S 2 ) 


Plsi = false (n, C2, entry, Si) J, (L, S2) 

If False - 

(n, if B then Ci else C2 fi,entry. Si) J, (L, S2) 

(n,C2,z,Si)i(L,S2) 

If 2 - 

(n, if B then Ci else C2 f i, /, Si) J, (L, S2) 

PI Si = true 
(n,Ci,entry,Si)i(/,S2) 

While True 1 - 

(n, while B do C od, entry, Si) J, (Z, S2) 

(n,Ci,Zi,Si)i(Z2,S2) 

While Seg 1 - 

(n, while B do C od, Zi, Si) J, (Z2, S2) 


(U,C,,l,S,)i(L,S2) 

If 1 - 

(n, if B then Ci else C2 f i, Z, Si) J, (L, S2) 

Pis = false 

1? Th a T CT? _ 

(n, while B do C od,entry,S) J, (exit,S) 

PIsi = true (n, Cl, entry. Si) J, (exit, S 2 ) 

(n, while B do C od, entry, S 2 ) J, (i, S 3 ) 

While True 2 - 

(n, while B do C od, entry. Si) J, (L, S 3 ) 

(n,Ci,Z,Si)i(exit,S2) 

(n, while B do C od,entry,S 2 ) i (i, S 3 ) 

While Seg 2 - 

(n, while B do C od, Z, Si) i (L, S 3 ) 


Figure 8. The Fine-Grained Semantics 


state, but rather the segments of reentry calls that connect 
entry points and exit points do the job. 

There are similarities among semantics for different com¬ 
positional commands, and we will take the sequence com¬ 
mand for demonstration in Figure 9. 



SEQ SEQI SEQ2 


Figure 9. Semantics for Sequence Command 

If the execution of program Ci starts from some label Li 
with program state Si and quits from the exit with S 2 , and 
the execution of program C 2 starts from the entry with state 
S2 and terminates at some label L 2 with S3. Then by Seq, we 
may connect two execution traces and obtain the trace that 
starts from Li with state Si and terminates at L 2 with S3. 

If the execution of Ci does not quit from the standard exit 
but instead breaks out through some reentry point Z as a 


reentry call, then following SeqI, the effect of C2 is blocked 
because the execution trace leaves the entire program from 
Z, before reaching the second part. Similarly, if the execution 
begins by returning to the reentry point at Z in C2, the exe¬ 
cution trace will not go through Ci, which does not affect 
the program state according to Seq 2. 

In summary, the fine-grained semantics only describes 
the binary relation of states on a single execution trace from 
one label to another. The trace should not be interrupted by 
any reentry call, i.e., no reentry line number is allowed as an 
intermediate label. The semantics is enough for supporting 
the definition of fine-grained validity since both only talk 
about preconditions and postconditions along segments of 
execution traces within the contract. The reentry semantics 
proposed in §5.1 can connect those traces and bridge this 
semantics to the coarse-grained semantics. 

The white-list F does not occur in the fine-grained se¬ 
mantics because this semantics does not describe the real 
happenings during reentrancy and there is no need to know 
which functions are reentrant. 

Based on the previous interpretation of the quintuple, we 
then define a quintuple having fine-grained validity (D 1= / : 
{P}{.Ri}{.R 2 }{ 0 }) if and only if the following criteria hold: 
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• n t^pQ f : iff- for the evaluation 

(n, bdyn(/), entry. Si) J, (exit, S 2 ) from the standard 
entry to the standard exit of function /, if Si satisfies 
P, then S 2 satisfies Q. 

• n i^pR f : {f’}{^i}{^ 2 }{C} iff- for the evaluation 
(n, bdyn(/), entry, Si) J, (/, S 2 ) from the standard en¬ 
try to any reentry point / in function /, if Si satisfies 
P, then S 2 satisfies the reentry assertion f? 2 , (/,/> at 1. 

• n i^RQ f : {f’}{^i}{^ 2 }{Q} iff- for the evaluation 

(n, bdyn(/), I, Si) J, (exit, S 2 ) from any reentry point 
I to the standard exit of function /, if Si satisfies the 
reentry assertion at /, then S 2 satisfies Q. 

• n t^RR f : {f’}{^i}{^ 2 }{C} iff- for the evaluation 

(n, bdyn(/), Zi, Si) J, (Z 2 , S 2 ) from any reentry point Zi 
to any reentry point I 2 in /, if Si satisfies the reentry 
assertion at Zi, then S 2 satisfies the reentry 

assertion i^ 2 , </, (2 > at Z 2 - 

4.2 Examples 

4.2.1 DAO Example cont. 

We revisit the simplified DAO example (9) and use the quin¬ 
tuple specification below to express a more precise property 
about it. 

withdraw :{|[Z?aZawce| - n A |[Mser| = m} 

{I : ^balance^ — n A |[user| = m'} 

(13) 

{Z : ^balance^ — n A |[Mser| — m + n} 
{^balance^ —Q A |[user| = m'} 

When exiting the function withdraw from the reentry point 
Z, the variable user will increase its value by n. However, 
we never know what value it will be after the reentrancy 
finishes and returns to the function through Z. But we are 
sure that if it enters the function through Z with user set 
to some m', when the function terminates, it will still be m' 
and the balance will be 0. 

This quintuple specifies that each regular invocation or 
reentry call of the function would result in an increase of 
user with value n. Therefore, we can prove such a fact: if 
the user calls withdraw once and calls it k times during the 
reentrancy, then it wiU receive kn unit of ether. The previous 
coarse-grained logic cannot achieve this. 

4.2.2 Multi-Eunction Reentrancy cont. 

Now, we will use the fine-grained logic to describe the func¬ 
tional correctness and reentrancy properties of the contract 
in the toy example in §3.3.1. 

The specification of function / becomes the quintuple (14). 

/ -{1*1 = 0 A Ixl - k A k > 0} 

{h : PI = W A W = A: A fc > 0} 

{Zi : PI = W A Ix| = k A Zc> 0} 

{p'l — k A k > 0} 


where the precondition and the postcondition are the same 
as the triple ( 1 ), and the reentry assertion at l\ is the post¬ 
condition after the assignment of i. 

We use Figure 6 to illustrate two quintuples that describe 
the reentrancy properties of f and g. These three quintuples’ 
validities are easy to verify. 


S -{ 


{I'l = A n > 0} 


A 


W = «--11 
■ ' An > n 


I, : 


< - 

W = « + I 

A n > n 


> fi 


||[i| = n A n > 0} 


V- 


'{pl = nAn> 0} 


{h ■■ T} 


{Zi : ±} 


{p'l = re A n > 0} 


_Y 


Figure 10. Quintuples for Reentrancy in f and g 


It is obvious that given any sequence of reentry calls, we 
can always connect the postcondition at the previous exit 
point to the precondition at the head of next reentry call. 
And we can also connect the postcondition at the tail of 
current reentry call to the precondition at the exit point in 
the last level of reentry call. For example, we can connect 
reentry calls according to dashed lines in Figure 6 , along 
which derivations between assertions are valid. Eventually, 
it forms a paths from the precondition to the postcondition 
in the specification of function f. We generalize this intuitive 
result in §5 and will revisit this example in §5.4. 

5 Relationship between Two Logics 

In §3, we give a coarse-grained logic that can prove coarse¬ 
grained specifications, and in §4, we give a fine-grained logic 
that can prove fine-grained specifications but with more 
complex judgment. Given that users have proved some fine¬ 
grained properties in the fine-grained logic, they may directly 
derive valid coarse-grained specifications using those results. 
There is no need to go through another proof in the coarse¬ 
grained logic. In this section, we consider such a derivation 
between two logics. 

We first present the concept of the reentry stack and the 
reentry semantics that extends the fine-grained semantics 
proposed in §4.1. Then, we prove that this reentry semantics 
is equivalent to the standard semantics (in § 2 . 2 ) of our toy 
language. We then show how to derive valid triples in the 
coarse-grained logic based on valid quintuples in the fine¬ 
grained logic. Lastly, we resume the discussion of the toy 
example in §4.2.1 about the relationship between two logics. 





























Execute Command 


_ iU,C,Li,S,)i{L2,S2) _ 

{U,T,i{C,LuS^),Y)) iii (((C,L2,S2),S)) 


/ e r C 2 = bdyn(/) 

Enter Reentry Call --;-^-- 

(n, r, ((Cl, /, {Si, Sg)}, S)) IXi (((C2, entry, (S,', Sg)}, (Q, /, {Si, Sg)}, S)) 

Exit Reentry Call (H, T, ((C 2 , exit, (S,', S'g)), {C,, /, (Si, Sg)), 2)) Ui (((Q, /, (S,, S^)), 2)) 


Figure 11. Reentry Semantics 


5.1 The Reentry Semantics 

As we may model regular function calls using stacks to record 
state for temporary variables, we devise the similar concept 
of reentry stack for reentry calls as 

2 e|(C,L,S>,2 

where elements in the stack are triples of the program, the 
label marking execution progress, and the corresponding 
program state. 

The fine-grained semantics J, only specify the execution 
trace within the function, and now we present the reentry 
semantics in Figure 11, which models glue steps between 
execution traces in different functions. We use JJ,i to denote 
the single step relation in the reentry semantics. According 
to Execute Command, the effect to label and state in the fine¬ 
grained semantics can be directly apply to the top element 
in the reentry stack, i.e., the execution of the most inner 
reentry call obeys the fine-grained semantics. 

If the execution encounters a reentry point / in the most 
inner reentry call, it might trigger another reentry call at 
that point. As Enter Reentry Call indicates, the external 
contract can select one function f in the white-list F and 
push its function body C 2 into the top of the reentry stack. 
The label pushed in together is the entry, suggesting the 
execution of the new reentry call starts from the beginning. 
The global state inherits from the one Sg in the previous 
level, and the local state S' is initialized arbitrarily based on 
arguments passed in from the external contract. 

When the execution of the most inner reentry call meets 
its exit, we will exit the top level of reentry call by popping 
(C2, exit, (S', Sg)) out of the stack. Exit Reentry Call says, 
its global state Sg will now be assigned to the new top ele¬ 
ment, which is the closest level of reentry call to the finished 
one. And it then redirects the control-flow back to the pro¬ 
gram Cl at that level with its original local state S/ and the 
new global state S^, and it can choose to either continue the 
reentrancy-free execution from the reentry point or issue 
another reentry call. 

We use U,* to denote the multi-step relation in the reentry 
semantics. 


5.2 Equivalence between Two Semantics 

The reentry semantics can describe full execution paths just 
like the coarse-grained denotational semantics. In fact, they 
are equivalent. We only prove the direction from the coarse¬ 
grained denotational semantics to the reentry semantics here, 
which is used in the proof of the derivation theorem in §5.3. 

We first prove congruence lemmas for the reentry seman¬ 
tics. We use lemma 5.1 as an example to illustrate the core 
idea of these lemmas. Eemma 5.1 states that if the execution 
of the most inner call triggers a reentry call at line I 2 , we 
can extend the command by appending another command 
to its tail using the sequence command. We know the mod¬ 
ified relation still holds because the command C 2 does not 
participate in the execution from Li to I 2 . 

Lemma 5.1 (Congruence Rule for Seql). 

(n,r,((Ci,Li,Si),e)) ii* (n,r,((Ci,/2,S2),e)) implies 
(n, F, ((Ci;; C2, Li, Si), e)) (U, T, ((Ci;; C2, k, S 2 ), e)). 

There is one congruence lemma for each branch of every 
compositional command, and they are similar to lemma 5.1. 

We then give two equivalence theorems among the deno¬ 
tational semantics, the arbitrary evaluation relation, and the 
reentry semantics. 

Theorem 5.2. The effect of C to the program state in the 
denotational semantics can be applied to the top element of the 
reentry stack in the reentry semantics, i.e., 

(n, F, C, Si) jj (S2) implies 

(n, r, ((C, entry. Si), e)) jj,* (((C, exit, S 2 ), e)). 

Theorem 5.3. The effect of the arbitrary evaluation can be 
applied to the global state of the top element of the reentry at 
some reentry point I, i.e., 

n, r 1 = S^ '^ar S'g implies 

(n, r, ((c, i, {Si, Sg)), e)) li* («c, /, s(s,, s;)), e)). 

Theorem 5.2 and theorem 5.3 can be proved by mutual 
induction with the help of congruence lemmas. Please refer 
to our Coq formalization for detailed proofs. 
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5.3 From Fine-Grained Judgments to 
Coarse-Grained Judgments 

We are now at the stage to show how to produce valid triples 
in the coarse-grained logic using valid quintuples in the fine¬ 
grained logic. For example, we can prove triple (1) valid given 
that quintuple (14) and quintuples in Figure 10 are valid. 

On the side of the fine-grained logic, we can use it to 
describe the reentrancy property of the contract using pa¬ 
rameterized invariants and transition relation of parameters. 

We define the mapping of parameter type A, the contract 
invariant I, and the local reentry assertion % as follows. 

A : index —» Type 
1,'R : A{i : index).A; —> Assertion 

The A defines the valid parameter set for each index, and the 
contract invariants I and local reentry assertions "R spec¬ 
ify parameterized assertions at reentry points. It is worth 
mentioning that we can only use invariants to describe the 
reentrancy. Because for any precondition at the reentry point, 
if its strongest postcondition differs from the precondition, 
it means we have assumed external contract has modified 
the program state, where it could choose to do nothing dur¬ 
ing the reentrancy, and this conflicts with the assumption. 
However, invariants can also be flexible if parameterized as 
we will demonstrate in our example. 

We specify the transition relation between parameters as 

R : X{i,j : index).Aj — > Aj —> Prop 

The most intuitive type of parameters is the depth of nested 
reentry calls, where the transition is increasing or decreasing 
the depth by 1, and we can reason about different invariants 
at different stages of reentrancy. By specifying I, R and R, 
one can determine reentrancy properties of the contract. 

We define the notation below as a shorthand for the valid¬ 
ity of function triples in the coarse-grained logic. 

n,r ^ /: {P}{Q} ^ n,r ^ mbdyn(/){e} 

Then we provide the derivation theorem 5.4. 

Theorem 5.4 (The Derivation Theorem). Given the contract 
invariants I, the local reentry assertions R, and the transition 
relation of parameters R, we can have the validity Ft, F 1= / : 
{P}{Q} if the following conditions are satisfied: 

1. Global Assertion: Contract invariants are global asser¬ 
tions, i.e., for any reentry point i with any parameter x, 
we have globalP{Ii{x)) and localPiRfx)). 

2. Initial Condition: For the given specification f : {P}{2} 
of the target function f, we haveH 1= / : {P}{f}{f}{0}, 
where we construct the invariant Ifor any reentry 
point I using I andR as 3z.I(jifiz) AR(jifz). 

3. Reentry Conditions: For any possible reentrant func¬ 
tion f e F, if the current reentry call starts from some 
reentry point i with parameter x, we have 11 1= /' : 


{Ii{x)}{I}{I}{Ii{x)}, where the invariant f at any reen¬ 
try point j in f is 3y.{x, y) e Rij A Ijiy) A Rfiy). 

To prove the theorem, we need to prove the conclusion for 
a generalized precondition about the reentry stack below. 

Given fixed IF, F, A and the target function /, for the reen¬ 
try stack S with the precondition P, the postcondition Q, the 
contract invariants I, and the the local reentry assertions R, 
we then define the reentry stack invariant !P(T, P,Q,I, R) 
to be true if and only if the followings are true: 

1. If S has only one bottom element (bdyn(/), entry, S), 
then the program state satisfies the precondition S 1= P; 

2. If S has only one bottom element (bdyn(/), exit, S), 
then the state satisfies the postcondition S Q; 

3. If S has only one bottom element (bdyn(/), /, S), then 
the program state satisfies both the invariant and local 
assertion S 1= I(jj){x) A Rijjfix)-, 

4. If E has more than one level, then for any index pa¬ 
rameter pair (i, x) at some level of S and the pair (J, y) 
at the level above it, we have (x, y) e Rij. And for 
the top element (bdyn(/'), L, S) and the next-level ele¬ 
ment (bdyn(/"); there should exist a parameter 
y : A(jnji), and one of the followings should be true. 

a. If the label L is entry or exit, then the program state 
should satisfy the invariant at the reentry point in 
the next level S I(j" i'fiy); 

b. If the label L is some reentry line number /, then 
there should exist some parameter x satisfying the 
transition relation (y, x) e R(jr> ir^^ (j/j) and the pro¬ 
gram state should satisfy both the invariant and the 
local assertion S 1= I(j>jfix) A R(j> ifix). 

We can prove theorem 5.4 by proving lemma 5.5. The 
detailed proof is in our Coq formalization. 

Lemma 5.5. Given three conditions in the derivation theorem, 
for any intermediate reentry stack S such that 

(n, F, ((bdyn(/), entry. Si), e)) fi* (S) 

(n,r,E) fj,* (((bdyn(/),ex/f,S 2 ),e)) 

If the generalized precondition'P(Z,P,Q, I ,R) is satisfied, we 
have S 2 1= Q. 

5.4 Example: Simple Reentrancy cont. 

Then we continue the discussion of the toy example in §4.2.2 
to demonstrate the derivation theorem we have proposed. 
First we define the parameter type at both reentry point 
h, I 2 to be integer. We define the transition relation between 
parameters as 

Rij = {(w, n4-l)\j - {g, I 2 ), n e N} 

where we can only transit from any index to index at f by 
increasing the parameter by 1. And we define the contract 
invariants and local reentry assertions as 

I_{n) = |[i| — n A n > 0 
= Hxl = k A k = n R^gj^fin) = T 
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which are apparently global assertions. 

We construct the invariant in the initial condition as 
4 = 3z.I(fj^)(z) A |[x| = /c A A: = z 
PI = W A |[x| = A: A A: > 0 

which resembles the invariant we construct in triple (8) when 
using Reentry rule to prove the specification. This is also 
equivalent to the assertion at li in quintuple (14). Therefore, 
it satisfies the initial condition since the quintuple is valid. 
We construct the invariant in the reentry conditions as 

4 - 3i/.(n,y) e Ru{gJ^) M{gj^){y) ± 

4 - 3y.(n,y) e Ru{g,i^) Mi^gj^){y) 

<=^|[!| = n + lAu>0 

The again resembles the invariant we construct in triple (6). 
Moreover, they are equivalent to reentry assertions at Zi and 
h in Figure 10. Therefore, the reentry conditions also holds, 
and we conclude that the triple (1) is valid. 

This example walks through the entire derivation theorem 
to prove some valid coarse-grained triple using fine-grained 
quintuples. And it gives a deep insight into the relation be¬ 
tween the proof using the Reentry rule and the proof using 
the derivation theorem. To summarize the relation, if the 
coarse-grained specification can describe the correctness of 
the function, there would exist invariants to complete the 
coarse-grained proof and bridge the judgments in two logics. 
In these cases, two logics have the same expressiveness. 

6 Completeness of the Coarse-Grained 
Logic 

We have shown the derivation of coarse-grained specifica¬ 
tions using fine-grained properties in §5. But for those who 
only want coarse-grained specifications, the coarse-grained 
logic in §3 is enough to prove any of those, as long as the 
specification is valid. In this section, we give the complete¬ 
ness of the coarse-grained logic. 

Theorem 6.1 (Completeness). Assuming the assertion lan¬ 
guage has expressiveness, then there exists some function as¬ 
sumptions A such that 

V{ 4 }/{e'} e A.n,r,A H {P'}bdyn(/){g'} 

and for any valid triple 

n,T^{P}C{Q} 

it is also provable 

n,r,AH{p}c{g} 

Proof. We first construct the A as 

A = {{P'}/{ 0 '}|n,r ^ {P'}bdyn(/){g'}}. 

Then we prove the theorem by induction over the structure of 
C, and proofs are as normal for all cases except the reentry 
case, which is proved by lemma 6.2. □ 


Lemma 6.2. Assuming the assertion language has expressive¬ 
ness, then for the valid triple about reentry command 

n, r 1 = {P}reentry{Q} 

we have 

n,r, A I- {P}reentry{Q} 

where we construct the A as a set of valid function triples 

A = {{P}/{C}|n,r ^ {P}bdyn(/){C}}. 

Proof. We prove the Hoare triple by constructing intermedi¬ 
ate invariants as 

KS'i) ^ {(S,, Sg) 1 3s;.(s;, S'g) ^ P and r, n ^ S'g Sg} 

which contains all states that are reachable during the reen- 
trancy. 

We simply use the local assertion below to describe the 
local state 

RiS'^) ^ {{Si,Sg)\Si ^ S[} 

Firstly, it is clear that the precondition P can derive our 
invariant since the P is contained in /(S/) as the element 
where arbitrary evaluation takes zero step. 

P h 3Si.RiSi) A HSi) 

To apply the Reentry rule to step forward, we need to 
prove the invariants is in function assumptions for any / e F 

{(3S,.P(S0 A I(Si))}f{(3Si.RiSi) A liSi))} e A 

which means the function triple is valid. The proof is also in¬ 
tuitive, since I{Si) have included all states that are reachable 
during the reentrancy, and we can append / to the arbitrary 
evaluation relation to prove the validity. 

Now, we have shown that 3S; .P(S/) A F(S/) is the strongest 
postcondition of reentry. Combined with the validity of 
{P}reentry{Q}, we know that 3S/.P(S/) A 7(S/) i- Q holds. 
We can then clear the proof by Consequence rule. □ 

7 Related Work 

There have been surveys looking into the loopholes similar 
to the reentrancy bug of Ethereum smart contracts [6] [11]. 
They study the security vulnerabilities in the Ethereum smart 
contracts and classify different leaks that occur in smart 
contracts posing threats to their security into categories. The 
comprehensive taxonomy of vulnerabilities they present is 
of great assistance in identifying and studying security issues 
of smart contracts. Their informal analysis of possible causes 
under these vulnerabilities can help developers avoid such 
mistakes, as well as lead formal verification researches into 
resolving these problems. 

Hirai [16] formally defines the Ethereum Virtual Machine 
and its operational semantics on the instruction level in Lem, 
so that it can be compiled to support interactive theorem 
proving for Ethereum bytecode in other environments. His 
work lays the foundations for later research into the verifica¬ 
tion of smart contracts. He also suggests that we can model 
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the reentrancy behavior as an adversarial environment step, 
which is valid to change the program state of the contract 
only when it obeys certain invariants. The idea is similar to 
ours, though his work does not implement it formally. 

Bhargavan et al. [8] apply the F* framework to verify the 
runtime safety and functional correctness of Solidity con¬ 
tracts. They can detect dangerous patterns, including reen¬ 
trancy, only by typechecking possible reentrant methods. 
Grossman et al. [14] propose a notion of Effectively Callback 
Free (ECF) object, of which the security can be guaranteed if 
we can eliminate callbacks in all of its execution traces. They 
formalize the idea at the level of operation semantics, which 
bears certain similarities to our definition of the denotational 
semantics for the reentry call. Their work and Hirai’s work 
[16] are delivered only at the semantic level, which may 
serve as great models formalizing smart contracts but would 
be more useful when they can reason about the correctness 
and safety of the contract at the logic level. 

To assist researchers to approach the functional correct¬ 
ness of smart contracts at the logic level, Ahrendt et al. [2] 
outline a research agenda for the deductive verification of 
smart contracts at the source code level. The authors admit 
the difficulty of reasoning about security when dealing with 
reentrancy attacks that use non-functional aspects. 

Building on the existing EVM model [16], Amani et al. 
[3] develops a program logic for reasoning about smart con¬ 
tracts in the EVM bytecode form. But they do not explore 
the reentrancy bug in detail and they do not analyze smart 
contracts at the source code level. 

Nielsen and Spitters [22] formalize the blockchain along 
with smart contracts deployed on it in Coq as abstract models, 
and they can reason about the specification of a contract at 
bytecode level. But they do not provide a program logic for 
source code level reasoning. 

Kalra et al. [18] make analyzing source code of smart 
contracts available by demonstrating Zeus, a framework 
for verifying the correctness and validating the fairness of 
smart contracts presented in high-level languages. They also 
formulate strategies for detecting reentry bugs. Eiu et al. [21] 
propose the ReGaurd, a fuzzing-based analyzer that targets 
the detection of reentrancy bugs. However, these strategies 
are independent of the functional verification of the contract. 

Another source-level verification tool for smart contracts 
is the SOLC-VERIFY devised by Hajdu et al. [15]. Users may 
write specifications as annotations in the code, and the ver¬ 
ifier will verify whether the program states are consistent 
with specifications. However, the tool uses SMT-solver based 
methods for verification, so it cannot handle higher-order 
cases. Furthermore, it does not provide a clear program logic 
like ours. Although detection for reentrancy bugs is also 
available in this system, they fail to show the soundness of 
their approaches. 

As for the analysis of reentrancy bugs, we can also model 
them as their counterparts in the concurrent programs. Sergey 


and Hobor [23] identify the similarity between the smart 
contract with conventional concurrent programs and seek to 
understand the behavior of smart contracts by considering 
them as concurrent objects. In this way, many loopholes in 
smart contracts can be analyzed based on formal verification 
techniques for analyzing concurrent programming context. 
Nevertheless, their research provides no formalization of the 
idea, which might be worthy of further development. 

A different approach to deal with the security of smart 
contracts is runtime loophole detection and protection. Cook 
et al. [13] elaborate on a real-time monitoring and protecting 
system for Solidity smart contracts that collect information 
from the blockchain network and tracks potential attacks to 
the contract. When establishing the concept of ECF, Gross- 
man et al. [14] also invent an algorithm for the online detec¬ 
tion of ECF and evaluated it on the history of the blockchain. 
These systems are of great aid to the protection of deployed 
contracts, but it is not for identifying and locating loopholes 
in the contract beforehand. Since we can not recall contracts 
deployed on the blockchain, the detection of bugs before 
deployment is considered more economical. 

8 Conclusion 

In this paper, we have presented two program logics about 
reentrancy behaviors. Our coarse-grained logic can prove 
coarse-grained specifications and is both sound and complete. 
However, its triple lacks expressiveness when we want fine¬ 
grained function specifications to connect execution results 
with other hyper-parameters of reentrancy (e.g. the number 
of times reentry call happens, the order of different reentry 
calls and the parameters of reentry calls). In comparison, 
our fine-grained logic can use relatively complicated quin¬ 
tuples to specify not only preconditions and postconditions 
of functions, but also assertions of program state at each 
reentry point. These reentry assertions include the effect of 
reentrancy hyper-parameters into function specifications. 
Nevertheless, we sometimes would need several complex 
quintuples to cover specifications for a function thoroughly. 

It is unclear whether we can use one Hoare-triple-like 
specification to describe a fine-grained property. Recently, 
interaction trees [19] are used to describe possible interac¬ 
tions between different threads in an assertion. It is possible 
for us to apply the concept of interaction tree to handle reen¬ 
trancy, if we treat reentry calls as interactions between the 
contract and external callers. We will investigate the idea in 
the future. 

Our contribution in this paper is mainly theoretical but 
we also show how to formalize these results (about a toy 
language) in a theorem proven In order to establish end- 
to-end functional correctness of real Solidity contracts, an 
interactive verification tool should contain the following 
components: 

• A formalized semantics for real Solidity language; 
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• A formalized semantics for Etheurem VM bytecode; 

• A verified compiler from solidity to Etheurem VM 
bytecode; 

• A coarse-grained logic and fine-graned logic for So¬ 
lidity, which is formally proved sound w.r.t. Solidity’s 
semantics; 

• A verified symbolic execution library, which is based 
on logics above and can provide some proof automa¬ 
tion support. 

We believe that all of these components above can be done 
by a reasonable amount proof engineering, according to our 
results in this paper and successful experience of previous 
program verification projects. Specifically, the famous Com- 
pCert [? ] project provides a general framework to define 
formal small step semantics for realistic programming lan¬ 
guages (e.g. C and assembly), to develop a verified compiler, 
and to connect a small step semantics with a big step seman¬ 
tics (like our denotational semantics in this paper); the VST 
project [10] shows how to formally prove a program logic 
sound (whose proof would be concise and elegant on toy 
languages) w.r.t. a realistic programming language (while all 
language subtleties are taken into consideration), and how 
to implement a verified symbolic execution system based 
on such logics above and based on a theorem prover’s tactic 
system. 
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